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PKFTTMINARY AMENDMENT 

Prior to examination, please amend the replacement specification as follows: 
In the specification ; 

Insert the following drawing descriptions at the end of the paragraph ending on page 4, 
line number 30: 

□ FIG. 17 is a block diagram illustrating the typical storage stack in a controller/server or a 

m client. 

ffl FIGs. 1 8 and 19 are block diagrams illustrating the disk and the tape drivers providing 

m access to physical data. 

1 y FIG. 20 is a block diagram illustrating two servers that are connected on a LAN/WAN. 

O FIG. 2 1 is a block diagram illustrating a framework in which the Virtual Volume 

iff Management Protocol may operate. 

£ FIG. 22 is a diagram illustrating the Virtual Volume Management Protocol, 

ffi FIG. 23 is a block diagram illustrating a data path management example. 

FIG. 24 is a block diagram illustrating an instance of SAN/WAN interoperability using 
VVMP. 

FIG. 25 is a block diagram illustrating a generic computing subsystem that supports both 
SANandNAS. 
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FIG. 26 is a block diagram illustrating three SAN domains, each managed by a SAN 
manager and having heterogeneous disk arrays. 

Insert the following paragraphs after the paragraph ending at page 21, line number 9, as 
follows: 

The following devices can make the data delivery possible to the applications: 
Storage Devices: Disk, Tape 

Storage Controllers: RAID, Disk & Tape Controllers 
Access Controllers: Server, Switch 
Access Managers: Server, SAN Managers 
H> Data End Points: Servers, Clients 

n The Storage devices are typically dumb magnetic platters that store the data. The storage 

? controllers have intelligence and can be either host bus adapter or an external controller closer to 

C3 

W the disk/tape. The access controllers today are the servers, which define the criteria for the access 
pi to data. The switch can perform this action in the future. The data access manager or the data 
*_ manager is a client or a server today and can-be the SAN managers or switches in the future. The 
jji data end points are applications that reside in the clients and the servers today. 

SK;; 

*| FIG. 17 represents the typical storage stack in a controller/server or a client. Referring to 

O FIGs. 17, 18 and 19, the disk and the tape drivers 1701 give the access to the physical data. The 
data can be stored on a RAID array 1801, 1901 or 1902 in case of which, the RAID layer 1702 
will provide the access to the data. Multiple RAID arrays 1801, 1901 and 1902 or JBODs 1802, 
1903 and 1904 can be clubbed together to form a stripe or a mirror 1803, 1905 and 1906. Many 
vendors like Auspex, Veritas, DEC, IBM support this model. 

The volume manager today assumes that all the members of the volume are locally 
attached. However, with the increasing reliability and speeds of the LAN and WAN, these disks 
can be LAN or WAN attached. 

FIG. 20 shows 2 servers 2001 and 2002 that are connected on a LANAVAN 2005. Each 
server has a RAID array 2003 and 2004 attached to it. The RAID arrays on both ends are sliced 
equally into 2 pieces, A & B. Say the pieces are named A-l, B-l & A-2 and B-2. A mirror can be 
defined on server-X that has A-l and A-2 as its members and mirror on server-Y has B-l and B-2 
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as its members. So when a write happens from server-X on A-l, the mirrored member A-2 also 
gets the data to be written, over the LAN/WAN. Today, many proprietary solutions exist to 
make this kind of topology happen. But each one of these solutions is different from one another 
and do not intemperate. 

Also with the advent of SANs and increasing adaptation of the SAN technology, these 
disks in FIG. 20 can be SAN attached. 

There is nothing that operates at the volume layer today, that can provide abstraction as to 
where the disks are physically attached. Also with the increasing need for interoperable 
solutions, this abstraction should support all the available standards of LAN/WAN/SAN. This 
abstraction can be provided using a new protocol that understands the semantics of LAN, WAN 

jM 5 and SAN. Auspex Systems Inc. initiated the definition of this new protocol and named it VVMP- 

o 

q Virtual Volume Management Protocol. The protocol should work in the frameworks shown in 

1 FIG. 21. 

G5 

bj As shown in FIG. 21, VVMP 2101 can be both in-band and out-of-band. 

Ill 

pi VVMP 2101 must take care of the horizontal storage methodologies and also on the 

vertical access methodologies, as shown in FIG. 22. 

VVMP 2101 must take care of the following devices: 
Devices that broadcast the storage parameters 
Devices that support downloading of the SAN characteristics 
Devices that are dumb (JBODs and Tapes) 
Devices that support other specific protocols (HiPPI....) 
VVMP 2101 must work with both: 
FiberChannel 
LAN/WAN Switches 

VVMP 2101 should support the following data path/session management functions for 
servers and clients (applications). 

Requests for storage with specific characteristics of type, capacity, bandwidth and QOS; 
request for a change in these parameters at a later time 

Mechanism for applications to register for storage allocation (on availability) 
Requests for storage with exclusive or shared access 



m 



n 
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Requests for additional storage or give away excess storage 

Request for automatic backup and mirroring 

Requests to include or exclude special hardware in the data path 

Request to show statistics for a particular data session 

Request to use RAID parameters like stripe size, cache line size, block size 

Security Management by creating storage domains 

Essentially VVMP 2101 is a Client-Server Protocol for Volume Management and setting 
up the Data Path - Data Path Management. FIG. 23 illustrates an example for the data path 
management. 

In FIG. 23, an application running on a server 2301 is using the video data on a RAID 
jj volume and the data is being compressed on write and uncompress on read using a compression 
3 hardware that is on the SAN. The SAN management 2302 has been instructed to set up the data 
2 path and the participating devices (compression hardware 2303, server 2301 and the RAID 
W controller 2304) are bound for the length of the data session. 

tzrf. 

m Figure 24 is another instance of SAN/WAN interoperability using WMP. Server A 

% 2401 and Server B 2402 use a volume X 2403. Server A 2401 has the volume connected over a 
IM local SAN and Server B 2402 accesses the Volume X 2403 over a WAN/SAN Combination 
I 2404. 

@ FIG. 25 shows a generic computing subsystem that supports both SAN and NAS. The 

disks can be attached on the SAN or connected on a LAN/WAN using a router 2501 . VVMP, 
though defined to be a data path management protocol, can encapsulate other protocols that can 
be used to setup the data path or manage it. E. g. 



VVMP 


NHRP for SAN 


VVMP 


DHCP for SAN 



NHRP for SAN can be a protocol that helps the application or the SAN manager discover 
the storage attached on other SANs. DHCP for SAN can be a protocol that can be used by the 
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edge devices to download SAN specific characteristics for the device. FIG. 26 shows 
interconnected SANs. 

FIG. 26 shows 3 SAN domains, each managed by a SAN manager 2601-2603 and having 
heterogeneous disk arrays 2604-2606. Each SAN has servers 2607-2609 and clients using the 
volumes that are created on the disk arrays 2604-2606. The following is an example of the 
VVMP protocol frame format. 



OPCODE 



Source SAN ID 



Source SAN ID 



Destination SAN ID 



Client ID 



Client ID 



Server ID 



m 



Server ID 



v 
== = 

m 



Sub OPCODE 



Transaction ID 



Length of Data in 32bit words 



Checksum 



Sample OPCODES 
0x0001 - Query Request 
0x8001 - Query Reply 
0x0002 - Allocate Request 
0x8002 - Allocate Reply 
0x0003 - Initialize Request 
0x8003 - Initialize Reply 
0x0004 - Free Request 
0x8004 - Free Reply 



Sample Sub OPCODES 
For Query 

0x01 - Query of SAN 
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0x02 - Broadcast for all devices 

0x03 - Broadcast for local devices 

OxFF - Broadcast of all devices on all SANs 

For Allocate 

0x01 - Local SAN only 

0x02 - Allocate with facility for expansion 

OxFF - Anywhere and all the above facilities 



Sample frame format for Allocate 



Storage Type 



Access Type 



Session ID 



M 1 

IP 



Capacity in KB 



Bandwidth in KB 



QOS 



Flags 



Timeout in msecs 



hi 



-3« 



Storage Types 
0x00 -JBOD 
0x01- RAID0 
0x02 - RAID2 
0x03 - RAID3 
0x04 - RAID4 
0x05-RAID5 
OxFF- Any type 



Access Types 
0x01 - SCSI 
0x02 - FC 
0x03 - HiPPl 
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0x04 - ATM 
OxFF - Any type 

Each data session will have a session ID, that is assigned by the WMP server, which 
typically is the SAN manager or a switch. The session ID is valid for the time of the session, 
which can be torn down by the client or the server or on a reboot of either of them. 

In FIG. 26, each volume manager (intelligent if it is a RAID/Tape controller or the SAN 
manager 2601-2603 itself in the case of JBOD) will broadcast its attributes periodically or in 
case of a query. The SAN Manager 2601-2603 will register it. In FIG. 25, when server-A 2607 
requests a RAID5 volume of lOOGB, the SAN-1 Manager 2601 will allocate the storage 
H depending on the parameters requested by the server. When all the storage in SAN-1 is 
q exhausted, the SAN-1 Manager 2601 can now go to other SANs to request the storage depending 
{J on the sub-opcode. 

jULil 

5 For the out-of-band management, WMP will use a reserved port on which the server 

m process will listen for requests. 

f% 

IJ1 Please delete Appendix A, pages 22-30, in the specification. 

; s I: 

• fy 

O In the drawings ; 

Please add sheets 17-22 attached. 
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REMARKS 



Attached is a marked-up version of the changes being made by the current amendment. 
Applicant asks that all claims be examined. No fees are believed to be due. If any fees 
are found to be due, please apply any other charges or credits to Deposit Account No. 06-1050. 



Fish & Richardson P.C. 
H; 500 Arguello Street, Suite 500 
5 Redwood City, California 94063 
2 Telephone: (650)839-5070 
£ Facsimile: (650)839-5071 

7£ ; 50088370.doc 



Respectfully submitted, 



Date: 





Katherine Kelly Lutton 
Reg. No. 46,333 
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Version with markings to show changes made 
In the specification: 

Insert the following drawing descriptions at the end of the paragraph ending on page 4, 
line number 30: 

FIG. 17 is a block diagram illustrating the typical storage stack in a controller/server or a 

client. 

FIGs. 18 and 19 are block diagrams illustrating the disk and the tape drivers providing 
access to physical data. 

FIG. 20 is a block diagram illustrating two servers that are connected on a LAN/WAN. 

u 

h FIG. 21 is a block diagram illustrating a framework in which the Virtual Volume 

y Management Protocol may operate. 

£§ FIG. 22 is a diagram illustrating the Virtual Volume Management Protocol. 

m FIG. 23 is a block diagram illustrating a data path management example. 

"^tf FIG. 24 is a block diagram illustrating an instance of SAN/WAN interoperability using 

b WMP. 

in 

pj FIG. 25 is a block diagram illustrating a generic computing subsystem that supports both 

p SANandNAS. 

m FIG. 26 is a block diagram illustrating three SAN domains, each managed by a SAN 

manager and having heterogeneous disk arrays. 



Insert the following paragraphs after the paragraph ending at page 21 , line number 9, as 
follows: 

The following devices can make the data delivery possible to the applications: 
Storage Devices: Disk, Tape 
Storage Controllers: RAID, Disk & Tape Controllers 
Access Controllers: Server, Switch 
Access Managers: Server, SAN Managers 
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Data End Points: Servers. Clients 
The Storage devices are typically dumb magnetic platters that store the data. The storage 
controllers have intelligence and can be either host bus adapter or an external controller closer to 
the disk/tape. The access controllers today are the servers, which define the criteria for the access 
to data. The switch can perform this action in the future. The data access manager or the data 
manager is a client or a server today and can-be the SAN managers or switches in the future. The 
data end points are applications that reside in the clients and the servers today. 

FIG. 17 represents the typical storage stack in a controller/server or a client. Referring to 
FIGs. 17. 18 and 19. the disk and the tape drivers 1701 give the access to the physical data. The 
data can be stored on a RAID array 1801. 1901 or 1902 in case of which, the RAID layer 1702 
H will provide the access to the data. Multiple RAID arrays 1801. 1901 and 1902 or JBODs 1802. 
§ 1903 and 1904 can be clubbed together to form a stripe or a mirror 1803. 1905 and 1906. Many 
5 vendors like Auspex. Veritas. DEC. IBM support this model. 

The volume manager today assumes that all the members of the volume are locally 
attached. However, with the increasing reliability and speeds of the LAN and W AN, these disks 
can be LAN or WAN attached. 

FIG. 20 shows 2 servers 2001 and 2002 that are connected on a LAN/WAN 2005. Each 
server has a RAID array 2003 and 2004 attached to it. The RAID arrays on both ends are sliced 
0 equally into 2 nieces, A & B. Say the pieces are named A-l B-l & A-2 and B-2. A mirror can be 
defined on server-X that has A-l and A-2 as its members and mirror on server-Y has B-l and B-2 
as its members. So when a write happens from server-X on A-l the mirrored member A-2 also 
gets the data to be written, over the LAN/WAN. Today, many proprietary solutions exist to 
make this kind of topology happen. But each one of these solutions is different from one another 
and do not interoperate. 

Also with the advent of SANs and increasing adaptation of the SAN technology, these 
disks in FIG. 20 can be SAN attached. 

There is nothing that operates at the volume layer today, that can provide abstraction as to 
where the disks are physically attached. Also with the increasing need for interoperable 
solutions, this abstraction should support all the available standards of LAN/WAN/SAN. This 
abstraction can be provided using a new protocol that understands the semanti cs of LAN, WAN 



m 

m. 



2 
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and SAN. Auspex Systems Inc. initiated the definition of this new protocol and named it VVMP- 
Virtual Volume Management Protocol. The protocol should work in the frameworks shown in 
FIG. 21. 

As shown in FIG. 21, VVMP 2101 can be both in-band and out-of-band. 
VVMP 21 01 must take care of the horizontal storage methodologies and also on the 
vertical access methodologies, as shown in FIG. 22. 

VVMP 2101 must take care of the following devices: 

Devices that broadcast the storage parameters 

Devices that support downloading of the SAN characteristics 

Devices that are dumb (JBODs and Tapes) 

Devices that support other specific protocols (HiPPI...) 
VVMP 2101 must work with both: 

FiberChannel 

LAN/WAN Switches 

VVMP 2101 should support the following data path/session management functions for 

servers and clients (applications). 

Requests for storage with specific characteristics of type, capacity, bandwidth and 
QOS; request for a change in these parameters at a later time 

Mechanism for applications to register for storage allocation (on availability) 
Requests for storage with exclusive or shared access 
Requests for additional storage or give away excess storage 
Request for automatic backup and mirroring 
Requests to include or exclude special hardware in the data path 
Request to show statistics for a particular data session 
Request to use RAID parameters like stripe size, cache line size, block size 
Security Management by creating storage domains 
Essentially VVMP 2101 is a Client-Server Protocol for Volume Management and setting 

up the Data Path - Data Path Management. FIG. 23 illustrates an example for the data path 

management. 
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m 



In FIG. 23. an application running on a server 2301 is using t he video data on a RAID 
volume and the data is being compressed on write and uncompress on read using a compress ion 
hardware that is on the SAN. The SAN management 2 302 has been instructed to set up the data 
path and the participating devices (compression hardware 230 3. server 2301 and the RAID 
controller 23041 are bound for the length of the data session. 

Fi gure 24 is another instance of SAN/WAN interoperability using VVMP. S erver A 
2401 and Server B 2402 use a volume X 2403. Server A 2401 has the volume connected over a 
local SAN and Server B 2402 accesses the Volume X 2403 over a WAN/SAN Combinati on 
2404. 

FIG. 25 shows a generic computing subsystem that supports both SAN and NA S. The 
disks can be attached on the SAN or connected on a LA N/WAN using a router 2501. VVMP, 
though defined to be a data path management protocol, can encapsulate other prot ocols that can 
be used to setup the data path or manage it. E. g. 



VVMP 



NHRP for SAN 



VVMP 



DHCP for SAN 



NHRP for SAN can be a protocol that helps the application or the SAN manager di scover 
the storage attached on other SANs. DHCP for SAN can be a protocol that can be used by t he 
edge devices to download SAN specific characteristics for th e device. FIG. 26 shows 
interconnected SANs. 

FIG. 26 shows 3 SAN domains, each managed by a SAN manager 2601-2603 and having 
heterogeneous disk arrays 2604-2606. Each SAN has servers 2607-2609 and clients using t he 
volumes that are created on the disk arrays 2604-2606. The following is an example of the 
VVMP protocol frame format. 



OPCODE 


Source SAN ED 


Source SAN ID 


Destination SAN ID 
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Client ID 



Client ID 



Server ID 



Server ID 



Transaction ID 



Sub OPCODE 



Length of Data in 32bit words 



Checksum 



Sample OPCODES 



IE 

RJ 

O 

i 



2p 



0x8001 


- Ouerv Reply 


0x0002 


- Allocate Request 


0x8002 


- Allocate Reply 


0x0003 


- Initialize Request 


0x8003 


- Initialize Replv 


0x0004 


- Free Request 


0x8004 


- Free Replv 


Sample Sub OPCODES 



For Query 

0x01 - Ouerv of SAN 

0x02 - Broadcast for all devices 

0x03 - Broadcast for local devices 

QxFF - Broadcast of all devices on all SANs 

For Allocate 

0x01 - Local SAN only 

0x02 - Allocate with facility for expansion 

QxFF - Anywhere and all the above facilities 



Sample frame format for Allocate 
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Storage Type 



Access Type 



Session ID 



Capacity in KB 



Bandwidth in KB 



OPS 



Flags 



Timeout in msecs 



en 



m 
m 



Storage Types 

0x00 -JBOD 



0x01- 


■ RAID0 


0x02 


-RAID2 


0x03 


-RAID3 


0x04 


-RAID4 


0x05 


-RAID5 



OxFF - Any type 



O 



0x01 - 


SCSI 


0x02- 


FC 


0x03- 


HiPPl 


0x04- 


ATM 



OxFF - Any type 



Each data session will have a session ID. that is assigned bv the WMP server, 
which typically is the SAN manager or a switch. The session ID is valid for the time of 
the session, which can be torn down bv the client or the server or on a reboot of either of 
them. 

In FIG. 26. each volume manager (intelligent if it is a RA ID/Tape controller or 
the SAN manager 2601-2603 itself in the case of JBOD') will broadcast its attributes 
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periodically or in case of a query. The SAN Manager 2601-2603 will register it. In FIG. 
25. when server-A 2607 requests a RAIDS volume of lOOGB, the SAN-1 M anager 2601 
will allocate the storage depending on the parameters requested by the s erver. When all 
the storage in SAN-1 is exhausted, the SAN-1 Manager 2601 can now go to other SANs 
to request the storage depending on the sub-opcode. 

For the out-of-band management VVMP will use a reserved port on which the 
server process will listen for requests. 



m 

- : :: 

•srsr 



APPENDIX -A 



Virtual Volume Management Protocol 

The following devices can make the data delivery possible to the applications. 



C 



Data Access 



] 



Storage Devices 
Disk, Tape 



X 



Storage Controllers 
RAJD. Disk & Tape 
Controllers 



± 



Access Controllers 
Server, Switch 



Access Managers 
Server, SAN managers 



Data End Points 
Servers, Clients 



The Storage devices are typically dumb magnetic platters that store the data. 
The storage controllers have intelligence and can be either host bus adapter or 
an external controller closer to the disk/tape. The access controllers today are 
the servers, which define the criteria for the access to data. The switch can 
perform this action in the future. The data access manager or the data manager 
is a client or a server today and can be the SAN managers or switches in the 
future. The data end points are applications that reside in the clients and the 
servers today. 





Volume Manaaer or Virtual Disk Manager 








A 




t 






RAID 




f 


t 


Disk/Tape Drivers 



Fig. 1 



The above figure represents the typical storage stack in a controller/server or a 
client. The disk and the tape drivers give the access to the physical data. The 
data can be stored on a RAID array, in case of which, the RAID layer will provide 
the access to the data. Multiple RAID arrays or JBODs can be clubbed together 
to form a stripe or a mirror. Many vendors like Auspex, Veritas, DEC, IBM 
support this model. 
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Fig. 2 



Striped Volume 



JBOD 



JBOD 



Stripe RAID Volume 



RAIDS 



RAIDS 



Fig. 3 



The volume manager today assumes that all the members of the volume are 
locally attached . However, with the increasing reliability and speeds of the LAN 
and WAN, these disks can he LAN or WAN attached . 
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Fig .4 shows 2 servers that are connected on a LAN/WAN, Each server has a 
RAID array attached to it. The RAID arrays on both ends are sliced equally into 2 
pieces, A & B. Say the pieces are named A-1, B-1 & A-2 and B-2. A mirror can 
be defined on server-X that has A-1 and A-2 as its members and mirror on 
server- Y has B-1 and B-2 as its members. So when a write happens from 
server-X on A-1 t the mirrored member A-2 also gets the data to be written, over 
the LAN/WAN. Today, many proprietary solutions exist to make this kind of 
topology happen. But each one of these solutions is different from one another 
and do not interoperate. 

Also with the advent of SANs and increasing adaptation of the SAN technology, 
these disks in fig. 4 can be SAN attached 

There is nothing that operates at the volume layer today, that can provide 
abstraction as to where the disks are physically attached. Also with the 
increasing need for interoperable solutions, this abstraction should support all the 
available standards of LAN A/VAN/SAN . This abstraction can be provided using a 
new protocol that understands the semantics of LAN, WAN and SAN. Auspex 
systems inc. initiated the definition of this new protocol and named it WMP- 
Virtual Volume Management Protocol The protocol should work in the 
following frameworks 



Applications or File System 



Snapshot and Data Management 



Volumes 



Virtual Volume Management Protocol - WMP 



Channels 

IPI/SCSI/HiPPl/Bus 
4Tag 



802.2/IP/ATM 



Common Services 



Framing Protocol / 
Flow Control 



Encode/Decode 



RAID 



266 Mbps/1862Mbps 

A 



Gbit/ATM 
OC3/1 2/48/96 



\J 



SAN 




Disk/Tape Drivers 



Fig. 5 



Local / Storage 
Framework 
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As shown in the above figure, WMP can be both in-band and out-of-band. 




WMP must take care of the horizontal storage methodologies and also on the 
vertical access methodologies, as shown in fig. 6. 

WMP must take care of the following devices 

> Devices that broadcast the storage parameters 

> Devices that support downloading of the SAN characteristics 

> Devices that are dumb (JBODs and Tapes) 

> Devices that support other specific protocols (HiPPI . . . .) 

WMP must work with both 

> FiberChannel 

> LAN/WAN Switches 

WMP should support the following data path/session management functions for 
servers and clients (applications) 

> Requests for storage with specific characteristics of type, capacity, bandwidth 
and QOS ; request for a change in these parameters at a later time 

> Mechanism for applications to register for storage allocation (on availability) 

> Requests for storage with exclusive or shared access 

> Requests for additional storage or give away excess storage 

> Request for automatic backup and mirroring 



25 



> Requests to include or exclude special hardware in the data path 

> Request to show statistics for a particular data session 

> Request to use RAID parameters like stripe size, cache line size, block size 

> Security Management by creating storage domains 

Essentially WMP is a Client-Server Protocol for Volume Management and 
setting up the Data Path - Data Path Management Following is an example for 
the data path management 




Data Path 



Fig.7 



In the above figure, An application running on a server is using the video data on 
a RAID volume and the data is being compressed on write and uncompress on 
read using a compression hardware that is on the SAN. The SAN manager has 
been instructed to set up the data path and the participating devices 
(compression hardware, server and the RAID controller) are bound for the length 
of the data session. 




Server B 



Figure 8 is another instance of SAN/WAN interoperability using WMP. Server A 
and Server B use a volume X. Server A has the volume connected over a local 
SAN and Server B accesses the Volume over a WAN/SAN Combination. 




Server Farm Fi g 9 



The above figure shows a generic computing subsystem that supports both SAN 
and NAS. The disks can be attached on the SAN or connected on a LAN/WAN 
using a router. WMP, though defined to be a data path management protocol, 
can encapsulate other protocols that can be used to setup the data path or 
manage it. E.g. 



WMP 


NHRP for SAN 






WMP 


DHCP for SAN 
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NHRP for SAN can be a protocol that helps the application or the SAN manager 
discover the storage attached on other SANs . DHCP for SAN can be a protocol 
that can be used by the edge devices to download SAN specific characteristics 
for the device. The following figure shows interconnected SANs 




The above figure shows 3 SAN domains, each managed by a SAN manager and 
having heterogeneous disk arrays. Each SAN has servers and clients using the 
volumes that are created on the disk arrays. The following is an example of the 
WMP protocol frame format 



OPCODE 



Source SAN ID 



Source SAN ID 



Destination SAN ID 



Client ID 



Client ID 



Server ID 



Server ID 



Transaction ID 



Sub OPCODE 



Length of Data in 32bit words 



Checksum 
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Sample OPCODES 



0x0001 - Query Request 
0x8001 - Query Reply 
0x0002 - Allocate Request 
0x8002 - Allocate Reply 
0x0003 - Initialize Request 
0x8003 - Initialize Reply 
0x0004 - Free Request 
0x8004 - Free Reply 

Sample Slid OPCODES 

For Query 

0x01 - Query of SAN 

0x02 - Broadcast for all devices 

0x03 - Broadcast for local devices 

OxFF - Broadcast of all devices on all SANs 

For Allocate 

0x01 - Local SAN only 

0x02 - Allocate with facility for expansion 

OxFF - Anywhere and all the above facilities 



Sample frame format for Allocate 



Storage Type Access Type 



Session ID 



Capacity in KB 



Bandwidth in KB 



QOS 



Flags 



Timeout in msecs 



Storage Types 



0x00 - JBOD 
0x01 - RAID0 
0x02 - RAID2 
0x03 - RAIDS 
0x04-RAID4 
0x05 - RAIDS 
OxFF - Any type 
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Access Types 



0x01 - SCSI 
0x02 - FC 
0x03 - HiPPI 
0x04 - ATM 
OxFF - Any type 

Each data session will have a session ID, that is assigned by the WMP server, 
which typically is the SAN manager or a switch. The session ID is valid for the 
time of the session, which can be torn down by the client or the server or on a 
reboot of either of them. 

In figure 10, each volume manager (intelligent if it is a RAID/Tape controller or 
the SAN manager itself in the case of JBOD) will broadcast its attributes 
periodically or in case of a query. The SAN Manager will register it. In figure 9, 
when server-A requests a RAIDS volume of 100GB, the SAN Manager-A will 
allocate the storage depending on the parameters requested by the server. 
When all the storage in SAN-A is exhausted, the SAN Manager-A can now go to 
other SANs to request the storage depending on the sub-opcode. 

For the out-of-band management, WMP will use a -reserved port on which the 
server process will listen for requests. 
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